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Abstract 

This paper presents research into providing highly 
reusable and maintainable components by using au- 
tomatic software synthesis techniques. This pro- 
posal uses domain knowledge combined with auto - 
' matic software synthesis techniques to engineer larae- 
; scale mission-critical real-time software. The hy - 
1 pothesis centers on a software synthesis architecture 
that specifically incorporates application-specific (in 
this case real-time) knowledge. This architecture syn- 
thesizes complex system software to meet a behav- 
ioral specification and external interaction design con- 
straints . Some examples of these external constraints 
are communication protocols, precisions , timing and 
- space limitations. The incorporation of application- 
specific knowledge facilitates the generation of math- 
ematical software metrics which are used to narrow 
the design space , thereby making software synthesis 
tractable. Success has the potential to dramatically re- 
duce mission- critical system life- cycle costs not only 
by reducing development time , but more importantly 
facilitating maintenance , modifications and extensions 
of complex mission- critical software systems which are 
currently dominating life-cycle costs. 

1 Introduction 

The software development process is time consum- 
ing, expensive, and fraught with errors. These char- 
acteristics hinder the reuse of software. This paper 
presents an approach that seeks to reduce software de- 
velopment time while simultaneously increasing soft- 
ware reuse. This approach, called RT-Syn, uses char- 
acteristics of the software domain to synthesize soft- 
ware. Although there is a wealth of structural and syn- 
tactic knowledge that can be brought to bear for soft- 
ware synthesis, the lack of success in generalized soft- 
ware synthesis [15] argues that this knowledge is in- 
sufficient, and tnat domain-specific knowledge is nec- 
essary for successful software synthesis. 

The chosen domain is real-time software. Software 
for real-time applications can be characterized as a 
set of time-constrained tasks. Real-time system fail- 
ure is defined as when any task misses its hard dead- 
line. Software development and subsequent redevelop- 
ment is one of the major bottlenecks of real-time sys- 
tem design and maintenance. One method to remove 
this bottleneck is to automatically synthesize real-time 
software to meet all system platform and task timing 
requirements. We argue that the presence of strict 


operation requirements, such as task-level timing con- 
straints and compiler and target platform constraints, 
can be used to guide synthesis. 

RT-Syn builds off of previous work by Setliff [11, 
12], Barstow [1], and Kant [9] among others. Gen- 
erality is supported by the use of a visual language 
as an algorithm specification. Only that application- 
specific knowledge relevant to programming-in-the- 
small synthesis is currently incorporated within the 
RT-Syn synthesis architecture. Within the vernacu- 
lar of this particular application domain, this current 
project focuses on task-level synthesis issues. Future 
work encompasses system-level (programming-in-the- 
large) synthesis issues. 

Section 2 reviews the current RT-Syn 1.0 architec- 
ture and presents a brief overview of each component 
within RT-Syn 1.0, including an enumeration of what 
knowledge is required to perform task-level synthe- 
sis and now that knowledge is represented. Section 
3 describes RT-Syn 2.0, an approach to system-level 
software synthesis. This section describes the various 
components envisioned within RT-Syn 2.0 and their 
interactions. Finally, Section 4 presents an overview 
of our progress and a plan for future work. 

2 RT-Syn 1.0 Architecture 

This section describes the architecture of our ini- 
tial version of RT-Syn called RT-Syn 1.0. This ver- 
sion incorporates knowledge of the effects of a specific 
platform, the DLX processor [4], on task-level synthe- 
sis, as well as an algorithm that uses this knowledge to 
formulate timing and space requirements estimates for 
different implementation possibilities for a task. We 
chose the simulated DLX processor for this initial ver- 
sion because it is completely modelled and DLXsim 
(a program which models the operation of the DLX 
processor) keeps statistics useful for checking our de- 
sign decisions. Current work in predictable platforms 
[18] seeks to design and develop real-world platforms 
which exhibit the similar predictable characteristics 
exhibited by the DLX processor. 

RT-Syn 1.0 integrates platform characteristics to 
synthesize a real-time software task to meet hard dead- 
line requirements. The RT-Syn 1.0 automatic syn- 
thesis system has five key features. First, a visual 
graphical user interface, called Intuition, captures ap- 
plication algorithms without implementation specifi- 
cations. Second, RT-Syn 1.0 analyzes the task-level 
data and control flows to produce worst-case timing 
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and space predictions. Third, RT-Syn 1.0 uses these 
predictions to select abstract representations of data 
structures and algorithm implementations to meet re- 
quired timing and space constraints. Fourth, RT-Syn 
1.0 synthesizes C code from the selected implementa- 
tions. Fifth, RT-Syn 1.0 validates the execution of the 
code to meet the predicted timing and space utiliza- 
tion values. 
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Figure 1: RT-Syn 1.0 Synthesis Architecture 

RT-Syn 1.0 (See Figure 1) is composed of several 
databases and two tools: Intuition, a graphical pro- 
gramming language, and CodeMaker, a real-time soft- 
ware directed program synthesis system. 

A visual programming language is a way to program 
a system using a visual paradigm. Visual program- 
ming languages vary in the level of represented detail 
[5]. Intuition provides a semantic-level, user-friendly, 
Hierarchical visual programming environment. This 
environment offers several advantages over text-based 
environments. It allows for the user-friendly input of 
RT-Syn specifications with minimum effort. Its hier- 
archical nature allows the user to easily modify the 
description. There is also less learning time involved. 
The concepts behind these advantages are present in a 
variety of existing visual programming research efforts 
[2,3,10,13,14]. 

Intuition acts as a user input system as well as a 
high level visual algorithm description. Intuition de- 
scriptions capture both data flow and control flow in- 
formation. Intuition is similar in form and function 
to the popular object-oriented drawing program that 
exists on personal computers, such as MacDraw. The 
user has a palette of tools, and a window in which to 
draw a schematic representation of algorithms. Fig- 
ure 2 is an example of a Intuition screen represen- 
tation of a FFT signal processing algorithm. Each 
rectangular cell on the screen represents a basic build- 
ing block of the algorithm. The building block may 
be direct computation or a hierarchical reference to 
another Intuition file representing quantities of com- 
putations. Data and control flow is captured by the 
connecting lines between the cells. There is no data 


Figure 2: Representative Intuition Algorithm Repre- 
sentation 

typing or language representation implied within Intu- 
ition. Groups of Intuition algorithmic representation 
formulate the Algorithm Database. This database or- 
ganizes the algorithms by function and by hierarchical 
components. 

The cornerstone of the RT-Syn 1.0 schema is a pro- 
gram synthesis system which is capable of produc- 
ing extremely well-modelled executable code. Code- 
Maker, a program synthesis system targeting real-time 
signal processing software, guarantees the validity of 
the generated code using the following methodology. 
First, CodeMaker analyzes all algorithmic represen- 
tations available within Intuition that can result in 
the required behavior and produces an internal rep- 
resentation of the algorithmic data and control flow. 
Second, CodeMaker uses knowledge of the platform 
to produce implementation ranges Tor each specifiable 
resource (currently, speed and space). All implemen- 
tation possibilities for a particular task are guaranteed 
to be within the implementation range. Third, Code- 
Maker analyzes the implementation ranges to select 
the algorithmic approach most likely to satisfy all of 
the required specifiable resource quantities for a par- 
ticular task. Fourth, CodeMaker then synthesizes an 
implementation of the algorithm that is guaranteed to 
meet the required specifications. 

The following example illustrates the operations 
within CodeMaker, what knowledge is applied, and 
how knowledge is applied. In this example, Code- 
Maker is directed (via Intuition) to synthesize a FFT 
algorithm that executes in X cycles and may consume 
no more than Y bytes of data memory. There exist 
numerous algorithms that exemplify the FFT behav- 
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ior [6]. Each algorithm, regardless of the implemen- 
tation, places a differing strain on computation and 
memory resources. CodeMaker must select a particu- 
lar algorithm and then synthesize an implementation 
of the algorithm to specifically meet the requirements 
for that task. 

CodeMaker first analyzes all algorithmic possibili- 
ties and produces a control and data flow graph for 
each. The implementation ranges are formed by not- 
ing a fairly simple fact. Timing limitations generally 
adversely affect space utilization (less time requires 
greater space requirements). To discover the mini- 
mum speed characteristic for any algorithm, synthe- 
size the algorithm while attempting to reach a ’time 
= O’ constraint. Of course, this is impossible so syn- 
thesis will fail, but the resultant implementation spec- 
ification will be the closest to zero and thus the min- 
imum time and maximum data memory. Setting a 
’space = O’ constraint and synthesizing to meet that 
constraint find the implementation that uses the least 
data memory and maximum time. Program memory 
requirements are not considered currently in Code- 
Maker. Each algorithm that satisfied the required be- 
havior is synthesized twice to produced implementa- 
tion ranges for that algorithm. The synthesis process 
incorporates knowledge of the platform and maintains 
any dependencies within an algorithm. This approach 
is used to prune out those possibilities that will fail 
early on in the process. The algorithm with a design 
space closest to the resource requirements is selected. 
It is important to note that the design space is not 
convex. There exist points in the design space that 
are not reachable. The synthesis process is capable of 
backtracking back to this point if the requirements are 
not attainable during the final synthesis process. 

Synthesis of an implementation requires access 
to specific platform-dependent data. The Platform 
Database contains modelling information needed to 
generate accurate predictions about the timing and 
space utilization characteristics of tasks for a given 
platform. The bulk of the information in this database 
consists of data about primitives. Primitives are the 
lowest-level building blocks used by RT-Syn when syn- 
thesizing C code. Typically, primitives represent sin- 
gle C operations, such as addition, multiplication, and 
branching operations. Information stored in the plat- 
form database includes: the timing and space charac- 
teristics of all primitives on this platform, formula to 
account of eccentricities in the behavior of the model 
of the platform, characterization of any operating sys- 
tem calls that will be used, and a characterization 
of the C compiler to be used when generating exe- 
cutable code. The behavior of platforms and compil- 
ers vary widely. As a basic example, some comput- 
ers utilize a separate floating-point math unit, which 
makes floating-point math a faster alternative to in- 
teger math. At a compiler level, different compilers 
perform different optimization techniques, so that the 
same piece of C code compiled on two different compil- 
ers and then run on the same platform will have differ- 
ent characteristics. An important feature of the RT- 
Syn system that is a result of the Platform Database 
is that a given set of tasks can be completely re- 


synthesized for different platforms by changing only 
the platform selection. 

CodeMaker uses the data and control flow graphs, 
in tandem with knowledge of the tradeoffs requisite in 
a particular target platform (e.g., operating system, 
hardware) and target language primitives, to select 
implementations. The selection process is performed 
bottom-up (or correspondingly output-back-to-input) 
on the data flow graph. This graph walking approach 
specifically acknowledges the impact of external re- 
quirements (the required outputs) on the implementa- 
tion selections. In this way, the external requirements 
are applied as early as possible and are used to re- 
ject portions of the design space that are unworkable. 
Only that knowledge pertinent to the task-level pre- 
diction and selection is required. Analysis, prediction, 
then selection continues until the task implementation 
is fully specified. At this point, the implementation 
code is constructed. 

Experimentation using Intuition and CodeMaker 
[16) demonstrate both the efficient synthesis (100’s 
of lines of code is less than 30 seconds on a MAC 
II) possible when application-specific knowledge is in- 
corporated within synthesis. Numerous experimenta- 
tion [16, 17] also shows the range of implementations 
attainable merely by modifying the task-level con- 
straints. These experiments show the power of using 
application-specific knowledge to synthesize software 
to meet a set of specifications and thereby provide for 
software reusability. Only knowledge of platforms and 
primitives particular to data structure and algorithm 
selection is incorporated and used within CodeMaker. 
This knowledge prunes the design space, while pro- 
viding solutions for time and space constrained signal 
processing tasks. 

RT-Syn 1.0, a real-time task set synthesis archi- 
tecture, synthesizes viable C code solutions based on 
a user’s high-level task set specification. RT-Syn 1.0 
takes as input a high-level description of the real-time 
tasks to be generated, along with information about 
the equipment on which the system will be run and 
generates code to implement each task. The code 
is guaranteed to meet any resource use requirements. 
The next section describes work in progress towards 
system-level synthesis using the successes of the RT- 
Syn 1.0 system as a foundation. 


3 Towards System-Level Synthesis 

RT-Syn 2.0 focuses on system-level synthesis. RT- 
Syn 2.0 performs all of the synthesis provided by RT- 
Syn 1.0 and also generates a scheduler to coordinate 
the execution of the individual tasks. The entire sys- 
tem will be guaranteed to produce the desired outputs 
within the given deadlines and without exceeding the 
host equipment’s resources. 

The RT-Syn 2.0 real-time software synthesis archi- 
tecture is shown in Figure 3. Each block in the dia- 
gram represents a component in the synthesis archi- 
tecture. There are two types of components in the 
synthesis architecture: design and database compo- 
nents. We first introduce each component, then de- 
scribe the advantages of this architecture. We then 
describe in detail the functionality of each component 


123 



Setliff 


User 

* 


System ■ — — 

Specification Intuition 


Resource 

.Database 




System 
Strategist 

VI 


'Algorithm 

.Database, 



Figure 3: RT-Syn 2.0 Synthesis System 


in the order that synthesis follows: from user specifi- 
cation of a set of tasks to the successful synthesis of 
code for each task. The software synthesis process is 
not monolithic; rather, the synthesis process is com- 
posed of a succession of abstraction levels. Breaking 
the software synthesis architecture into the various ab- 
straction levels illustrates the design hierarchy. Each 
design abstraction level is composed of a design com- 
ponent with database components as required. The 
highest abstraction level is the user interaction with 
the synthesis architecture. The System Specification 
component interacts with the user to form a system- 
level behavior description. The user interacts with the 
synthesis architecture via Intuition. 

The second abstraction level decomposes the sys- 
tem behavior descriptions into task level specifica- 
tions. The System Strategist component analyzes the 
system-level behavior description, determines what 
tasks are required, how the tasks are to be scheduled, 
and how resources are to be allocated to each task. All 
of these operations require knowledge. This knowl- 
edge is captured within three database components: 
the Resource Management Database, the Algorithm 
Database, and the Platform Database. The Resource 
Management Database contains knowledge of current 
system resource allocations and results from prior soft- 
ware synthesis operations. This information is used 
within the System Strategist to aid the design and 
synthesis process. The Algorithm Database contains 
knowledge about a variety of useful algorithms and the 


methods in which they are implemented. Each algo- 
rithm in this database is represented using Intuition. 
The Platform Database contains modelling informa- 
tion for various computer/compiler platforms. This 
information is used in the analysis tools within the 
System Strategist component and CodeMaker tool. 

The third abstraction level decomposes the task 
level specifications into code implementations. This 
abstraction level has already been developed and dis- 
cussed in a prior section of this proposal. 

There are several advantages to this architecture. 
The decomposition via abstraction level provides a de- 
sign focus and limits the amount of design search. The 
decomposition also closely mirrors the current devel- 
opment process of a system analyst and programmer. 
By mirroring this development process, it is possible 
to allow both system analysts and programmers to in- 
teract with the synthesis architecture. The distinction 
between design and database components provides a 
growth mechanism. 

Isolating the information into three distinct 
databases facilitates the expansion of RT-Syn 2.0 to 
work with a variety of systems. Extending the knowl- 
edge of the Algorithm Database enables the system to 
synthesize a wider array of tasks. 'Adding information 
about more systems to the Platform Database allows 
RT-Syn 2.0 to model new hardware/compiler plat- 
forms. Finally, by updating the Primitives Database, 
RT-Syn 2.0 gains the ability to synthesize code in dif- 
ferent languages. 

The System Specification component serves three 
functions. The first function is to enable the user to 
specify the set of tasks to be synthesized. The user 
specifies a type of task set (out of a list of tasks of 
which the system has knowledge), provides informa- 
tion about the number of and type of inputs and out- 
puts to the set of tasks, and chooses a target plat- 
form (from a list of machines for which there exist 
timing models). From this information RT-Syn 2.0 
constructs a suite of tasks which will perform the de- 
sired function and run within the confines of the tar- 
get platform’s constraints. The output is informa- 
tion to the System Strategist about what tasks are 
required and what platform is being used. This task 
specification information can be very coarse-grained 
(e.g., system-level input) or extremely detailed (e.g., 
implementation-level input), depending on the level of 
user interaction. The second function of the System 
Specification component is to interact with the user 
during the design and synthesis process. Interaction 
takes the form of behavior simulation. In this way, 
the user can validate that the set of tasks given in 
the input do indeed satisfy the required mathematical 
functionality before synthesizing to meet the needs of 
the application. 

The Resource Management Database provides in- 
formation about system resource allocation results to 
the System Strategist. As individual tasks are synthe- 
sized, the amount of resources required will solidify 
from coarse estimates to accurate predictions. Dur- 
ing the synthesis process, the Resource Management 
Database is updated to reflect the current state of a 
task’s resource allocation needs. These needs are rep- 
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resented as the set of task descriptors Ci, Ti and Ui 
(which represent worst-case execution time, execution 
period, and utilization, respectively) [8, 7]. 

The System Strategist acts as the systems analyst 
for the synthesis of the set of tasks. Its initial func- 
tion is to determine what task implementations will be 
used in the desired system and to choose and develop a 
real-time scheduler to manage these tasks. To choose a 
scheduler the System Strategist must have knowledge 
of a variety of scheduling schemas and have heuris- 
tics for deciding which one is most applicable to the 
current situation. These heuristics consist of rules de- 
rived from real-time scheduling theory. The following 
describes the algorithm database and provides a de- 
tailed discussion of the operations the System Strate- 
gist performs once the synthesis process is underway. 

There are two main characteristics of the Algorithm 
Database: organization and database entry contents. 
The algorithms are organized hierarchically by behav- 
ior. Figure 4 illustrates the organization of the Algo- 
rithm Database: 



Figure 4: Design Organization of the Algorithm 

Database 

The advantage of this organization is the reduction 
of search required to find all algorithms with a certain 
behavior. Organization by behavior places each algo- 
rithm in a specific behavior class. Each entry in a par- 
ticular class possesses the identical behavior but differs 
in the corresponding functionality. A behavior hierar- 
chy corresponds to the desired system-level user inter- 
action. A typical system level specification consists of 
a set of behavior descriptions. These behavior descrip- 
tions match particular class and subclass behaviors in 
the algorithm hierarchy. All algorithms corresponding 
to the specified behavior may be immediately retrieved 
for analysis. Each entry in the database is a 3-tuple: 
algorithm representation, resource constraint ranges, 
synthesis history. Each algorithm is represented in In- 
tuition. Each entry contains coarse-grained resource 
characteristics. These coarse-grained characteristics 
define the implementation design space for that algo- 
rithm entry. Currently the Algorithm Database con- 
tains time and space resource characteristics. 

The System Strategist analyzes the system-level be- 
havior description as a set of tasks, schedules each 


task, and allocates resources to each task in the sys- 
tem. The input to the System Strategist is a system- 
level behavior description. The output is a system 
scheduler algorithm selection, and a set of task-level 
descriptions. A task-level description details the be- 
havior algorithm and desired time and space char- 
acteristics for each task. Analysis is required to 
synthesize the scheduler algorithm and task-level de- 
scriptions. The System Strategist first accesses the 
implementation range information in the Algorithm 
Database for each task in the system. The set of 
implementation ranges defines the design space that 
the scheduling algorithm must guarantee. There is an 
enumerable set of scheduling algorithms. The System 
Strategist attempts to synthesize all known scheduling 
algorithms. The System Strategist applies the under- 
lying mathematics of each scheduling algorithm to the 
set of implementation ranges. A task specification is 
chosen within each range that will result in guaranteed 
schedulability. The set of task specifications may not 
overutilize system memory constraints. A potential 
scheduling algorithm is removed from consideration 
(pruned) when it fails to guarantee the task specifica- 
tion set. 

Scheduling algorithm analysis iterates with the syn- 
thesis of each task in the system. Task synthesis re- 
sults in more exact information than the implemen- 
tation range information in the Algorithm Database. 
More exact information prunes the design space and 
allows the reallocation of resources. 

4 Conclusions 

The real-time software development process is time 
consuming. This paper presents work in progress to- 
wards alleviating the costs of real-time software sys- 
tem design, development, and maintenance. This 
work incorporates state-of-the-art scheduling theory 
within a software synthesis architecture. This archi- 
tecture leverages off of past research into the successful 
synthesis of software. Results illustrating the ability 
to accurately predict the time and space characteris- 
tics of a task and then synthesize an implementation 
to meet the prediction can be found in [16, 17]. This 
synthesis system successfully generates functional C 
code from high-level algorithmic descriptions. The 
generated code can be modeled for speed and space 
requirements, and these predictions prove to be rea- 
sonably accurate for a variety of platforms. The abil- 
ity to generate predictable code is the cornerstone of 
the RT-SYN system. By demonstrating the validity 
of the synthesis system, we validate the premise of 
automated real-time task set synthesis. 

The scope of this paper presents work in the initial 
phase of tne design and development of a real-time 
software synthesis architecture. We target the syn- 
thesis of uni-task systems with a focus on the use of 
prediction to aid synthesis. Future work in this phase 
encompasses expanding the repertoire of algorithms 
within the Algorithm Database and verifying efficient 
synthesis of these algorithms. The second phase of this 
work targets on multi-task synthesis. Specifically, we 
will incorporate the RT Mach operating system into 
the Platform Database. We see this second phase as 
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proving the predictability of RT Mach by accurately 
predicting synthesis results. The third and final phase 
of this work targets system-level synthesis. At this 
point, we will introduce real-time network character- 
istics into the System Synthesis schedulability anal- 
ysis. These characteristics encompass adding a real- 
time database and system-level application scenarios. 
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